Add opt-in Alchemy deployment for the Cloudflare host - #1510
Conversation
|
|
||
| # Generate once with `openssl rand -hex 32`, then preserve it for the lifetime | ||
| # of this D1 database. Changing it makes stored encrypted credentials unreadable. | ||
| EXECUTOR_SECRET_KEY= |
There was a problem hiding this comment.
you can use Alchemy.Random btw
https://alchemy.run/cloudflare/security/secrets-env/#generate-tokens-with-alchemyrandom
There was a problem hiding this comment.
Thanks! Alchemy.Random makes sense for a fresh database. This path also supports adopting an existing Wrangler deployment, though, where we must preserve the exact existing EXECUTOR_SECRET_KEY. Otherwise credentials already encrypted in D1 become unreadable.
In beta.66, Random seem to not be able to ingest ingest/adopt an existing value and --adopt cannot recover the Worker secret plaintext, so I kept this as an explicit Config.redacted input.
https://github.com/alchemy-run/alchemy/blob/v2.0.0-beta.66/packages/alchemy/src/Random.ts
But maybe I'm missing something.
There was a problem hiding this comment.
ah makes sense, then this one is fine
| // converge instead of conservatively treating the directory as dirty. | ||
| assets: { | ||
| directory: HOST_ASSETS_DIR, | ||
| hash: assetsHash, |
There was a problem hiding this comment.
you shouldn't need to do your own hashing, assets should be doing that already
There was a problem hiding this comment.
I found that beta.66 hashes the assets when applying the Worker update, but the alchemy plan diff doesn’t hash the directory. Without supplying a hash, every plan shows the Worker as changed even when dist is unchanged. That’s why I added it, but I agree the custom hashing isn’t ideal. Would using Alchemy.Command.Build and passing its output hash be the intended approach, or would you rather I remove it and accept the conservative plans?
There was a problem hiding this comment.
that sounds like a bug, please make an issue on alchemy side, this is fine for now, if this PR gets merged without the fix being released, we can open a follow up PR later
There was a problem hiding this comment.
Does this help? alchemy-run/alchemy#1045
There was a problem hiding this comment.
Thanks, makes sense. I opened alchemy-run/alchemy#1047 and will leave the workaround as-is for now. If you have any other feedback on the PR, I’m happy to address it.
There was a problem hiding this comment.
@sam-goodwin Yep, this fixes it! I tested the patch against this stack: unchanged assets now plan as a no-op, and changing an asset correctly plans a Worker update. I’ll remove the workaround once the fix is released. Thanks!
Does this help? alchemy-run/alchemy#1045
What
Adds an opt-in Alchemy v2 deployment path for the existing Cloudflare host while keeping Wrangler as the default:
host-cloudflare-alchemyworkspace so Alchemy can use its required Effect version without upgrading Executor's runtime Effect dependency;validationcommands, adoption-aware production commands, shared remote-state bootstrap/authentication helpers, and explicit adoption safeguards;EXECUTOR_SECRET_KEY/keep_bindingsrisks.Cloudflare Access remains an external prerequisite with the pinned Alchemy release. Managed OAuth Access application support is being added upstream in alchemy-run/alchemy#1023.
Verification
bun run format:checkbun run lintbun run typecheckbun run --cwd apps/host-cloudflare test(23 tests)bun run --cwd apps/host-cloudflare buildplan:alchemy:validation: D1, R2, and Worker all no-opTURBO_TEST_CONCURRENCY=4 bun run testexits successfully. Its unchangedapps/cloud/src/account/org-api-key-revoke.node.test.tscurrently reports three pre-existing assertions caused by calls that omit the required organization selector header; the scoped Cloudflare host suite is green.